1. Field of the Invention
The invention generally relates to assessment of vulnerabilities in systems configured using software, and more particularly, to assessments using a system architecture model.
2. Description of the Related Art
There is a broadly recognized need for application security in all phases of the software development life cycle. A weakness in a software system, which can be a design flaw or an implementation error that allows an attacker to cause harm to stakeholders of the system is referred to as ‘vulnerability’. A threat model for a system configured using software may define a set of possible vulnerabilities that could result in compromises to the system. One approach to threat modeling involves identifying components and trust boundaries within an architecture model of the system. A trust boundary provides a demarcation within a system. On one side of the demarcation, data is believed to be trustworthy, and on the other side of the demarcation, data is believed to be untrustworthy.
A software-configured system architecture model provides a representation of behavior of a system configured using software. More particularly, the architecture model ordinarily represents the configuration of one or more component hardware machines (e.g., personal computers, network interface adapters, storage interface adapters, servers, routers, switches, etc.) according to computer software. It will be appreciated that configuration of a system of machines may be dynamic in that program code may configure machines to perform the roles of different system components at different moments during runtime operation. For example, at one moment, a machine (e.g., a computer) may be configured as a component that creates a network connection with a web server over the Internet, and at another moment, the same machine may be configured as a component that accesses a database within storage over a local area network.
There are a variety of ways in which to portray a software-configured system architecture model. One approach is to provide a high-level view of a system in terms of its principle runtime components (e.g., clients, servers, databases), their interactions (e.g., remote procedure call, event multicast, piped streams), and their properties (e.g., throughputs, latencies, reliabilities). Another useful approach involves a data flow diagram that shows principle runtime components and the data flow between them. A UML diagram can provide yet another view of an architecture model.
Trust boundaries identify regions of a software system architecture model that are especially vulnerable to attack, for example. For example, a software architecture model may indicate data movement across a trust boundary such as between the Internet and a company database server. Having been alerted to such trust boundary through the software architecture model, a developer may choose to carefully analyze potential vulnerabilities that may impact the security of data flow across the boundary and identify precautions that may be taken to mitigate the threat. Conversely, a developer may choose to scrutinize less thoroughly data that flows between components disposed entirely within the same trust level.
Different trust boundaries may be associated with different configurations of the components of a system. Trust boundaries are typically used in defining a threat model. As such they are a part of the system architecture model. There may be more than one kind of trust boundary. For example, there may be a “process boundary” separates two processes on the same machine and that demarcates a trust boundary between the processes. There may be a more generic trust boundary between a server and a user device to signify a lack of trust the server should have for the user if, for example, the user device accesses the system from the public internet. The effect of inserting trust boundaries into an architecture model is to adjust the set of threats enumerated. For example, inserting a trust boundary between two components that are connected by a communication channel alerts a software architect or security analyst, who are involved in building the system, of the possible need to require some form of authentication as a prerequisite to communication over the channel.
FIG. 1 is an illustrative drawing of a data flow diagram of an example software-configured system architecture model. This example architecture model includes three components, an interactor, i.e. a user device, a process, “My process”, and data storage. The architecture model shows that the data flow between the interactor and the process communicates commands sent by the user device to the process and communicates responses sent by the process to the interactor. The data flow between the process and the data storage communicates configuration information sent by the process to the data storage and communicates results information from the data storage to the process.
The illustrative architecture model of FIG. 1 includes a “trust boundary” between the process and the interactor, to indicate that the process may not trust the interactor and vice versa. Such a model may be created using a software based threat modeling tool, that runs on a computer system (not shown) by selecting architecture-level components from the tool's component library that best match the components of the actual system, and then choosing from the tool's connection library to choose architecture-level connection components that best represent the actual connections between the components of the actual system. Once an architecture model has been constructed, an architect or security analyst can identify trust and process boundaries within the resulting architecture model.
A threat modeling tool can be used to associate information about potential vulnerabilities with trust boundaries. A typical software based threat modeling tool identifies different potential mitigations for different kinds of threats. For example, in the illustrative model of FIG. 1, communications across the example trust boundary between the initiator and My Process may be vulnerable to a threat referred to as ‘tampering’. A threat modeling tool may identify several different kinds of possible tampering and may identify different mitigations that may be employed to address these different variations of the tampering threat. The identified threat mitigations may be used to build a more secure system. Note that a threat modeling tool may also enumerate threats that do not cross a trust boundary. However, these may be lower priority for a developer to consider mitigating although that is not guaranteed to be the case.
Computer program code encoded in a computer readable storage device that is developed and implemented pursuant to a system architectural model or conversely, that a system architecture model has been created to represent, is referred to herein as the ‘as-built’ code. The as-built code comprises the actual code implementation of a system design. The as-built code is used to actually configure one or more machines to physically act as the components specified within a system architecture model.
Unfortunately, there is an inherent mismatch between as-built software and an architectural level description of a system configured using the software. For example, the actual runtime structures of the as-built software may not even be known until the program executes. Clients and servers and communication channels (e.g., socket connections) may come and go dynamically (i.e., be instantiated and killed). Components (e.g., Dynamic Linked Libraries) not under direct control of the implementers may be loaded dynamically, and so forth. Thus, problems may arise because a software-configured system architecture can end up not being accurately representative of the as-built software system that ultimately is created.
Accurately representing the architecture of an as-built software system can be difficult for several reasons. Many computer systems contain millions of lines of code and are deployed on a variety of hardware. Further, software system design often is implemented by a number of developers, sometimes working from different locations. As a result of the complexity of the system's structure and interdependencies, it is not uncommon for different developers working to implement different parts of a system to introduce features or even changes to the overall system that are not reflected in the architecture model. Thus, an architecture model developed based upon a software design planned at the outset of a development process, for example, may end up to not be an accurate representation of the as-built system. Conversely, an architecture model designed after the implementation exists might not reflect all of the features and functionality or components of the as-built system.
Thus, there has been a need for improvement in the use of an architecture-level model to identify and mitigate potential vulnerabilities within a system containing components configured using software.